
%%%%% TABLA DE VERSIONES %%%%%

%\begin{tabular}{|c|c|c|c|}\cline{2-4}
%\multicolumn{1}{c|}{} & Fecha & Autores & Observaciones\\ \hline
%0.21 & 21-NOV & Cauchy-team & --- \\ \hline
%\end{tabular}

%%%%%%%%%%%%%%%%%%%%
% \begin{tabular}{|c|c|c|}\hline
% {\bfseries Frecuencias} & {\bfseries Consecuencias} & {\bfseries Niveles de riesgo}\\ \hline
% Frecuente: 1 vez al mes & Catastrófica: $>$2 meses, 10 \%;10 \% & Intolerable \\
% Probable: 1 vez cada tres meses & Crítica: $<$2 meses, -10\%;-10\% & Alto \\
% Ocasional: 1 vez al año & Seria: $<$1 mes, -5\%;-5\% & Medio\\
% Remoto: 1 vez cada 4-5 años & Menor: $<$15 días, -2\%;-2\% & Bajo \\
% Improbable: 1 vez cada 10 años & Ignorable: impacto no notorio & Tolerable \\ \hline
% \end{tabular}

\chapter{Introducción}

\section{Propósito}
	Este documento presenta el Plan de gestión de riesgos (\gls{RSGR}) del proyecto “Advanced Shop Manager (\gls{ADVSM})”, desarrollado por el Cauchy Team. El las siguientes subsecciones se presentan los riesgos identificados durante la \gls{faseInicio} del proyecto. Para cada uno de ellos se analiza la probabilidad de ocurrencia así como su severidad.
	
	La priorización de los riesgos identificados se hará con el criterio del nivel de riesgo, lo que nos permitirá determinar cuáles son los que tienen más impacto en nuestro proyecto y que por ende deben ser gestionados. De cada uno de éstos se valorarán sus efectos y contexto de aparición para el caso de que se convierta en un hecho. Además se definirán estrategias para reducir la probabilidad del riesgo o para controlar sus posibles efectos.
\section{Ámbito}
	El ámbito del análisis de riesgos será el del proyecto “Advanced Shop Manager” desde su fase inicial. No obstante parte de la información en él recogida es recomendable que se reutilice en otros proyectos semejantes.
	
	Será necesario durante el desarrollo del proyecto revisar y actualizar los contenidos del análisis de riesgos en caso de que se detecten nuevos riesgos no visibles en este momento.	
\section{Deficiones, acrónimos y abreviaturas}
	En el documento Glosario se encuentran todas las definiciones, acrónimos y abreviaturas utilizadas en este documento.
\section{Referencias}
	En este documento se hacen referencia a los siguientes documentos:
	\begin{itemize}
		\item Glosario
		\item Plan de Desarrollo de Software
		\item Plan de Proyecto de Software
		\item Actas de reuniones con el cliente
		\item Plan de Gestión de la Configuración del Software
	\end{itemize}
\section{Perspectiva general}
	En la sección 1 se muestran los objetivos de este documento así como los documentos a los que hace referencia y su estructura.
	
	En la sección 2 se expone la metodología de identificación y priorización de riesgos, se listan los riesgos identificados y se muestra una tabla de riesgos ordenada por nivel de riesgo. 
	
	En la sección 3 nos encargamos de la gestión de los riesgos, definiendo los planes de prevención y reducción del riesgo y los planes de contingencia de los riesgos con mayor impacto sobre el proyecto.
	
	En la sección 4 se expone una planificación temporal en donde se determinan los responsables del plan y los procesos a seguir para la identificación de nuevos riesgos y para el seguimiento del plan.
	
	En la sección 5 se hace un resumen de los resultados obtenidos.
	
\chapter{Identificación de riesgos del proyecto}

\section{Metodología}
	En esta sección listaremos los riesgos identificados en el proyecto. Posteriormente los priorizaremos para determinar qué riesgos gestionaremos en sucesivas secciones.

	Para la clasificación de riesgos, hemos utilizado la propuesta por Boehm adaptando la probabilidad y la consecuencia al tamaño de nuestro proyecto.
	
	La prioridad de los riesgos se asignará en función de:
	\begin{itemize}
		\item{\bf Probabilidad:} Probabilidad de que un riesgo se materialice con arreglo al siguiente baremo:
			\begin{itemize}
				\item{\bf Frecuente:} Una vez al mes.
				\item{\bf Probable:} Una vez cada tres meses.
				\item{\bf Ocasional:} Una vez al año.
				\item{\bf Remoto:} Una vez cada 4-5 años.
				\item{\bf Improbable:} Menos de una vez cada 10 años.
			\end{itemize}
		\item{\bf Severidad:} Mide la magnitud del trastorno provocado en el proceso de desarrollo.

					 La siguiente clasificación indica el retraso de la planificación, porcentaje de \gls{sobrecoste}, y porcentaje de reducción de la funcionalidad del producto respectivamente.
			\begin{itemize}
				\item{\bf Catastrófica:} Más de dos meses, aproximadamente el 10\%, aproximadamente el 10\%.
				\item{\bf Crítica:} Menos de dos meses, menos del 10\%, menos del 10\%.
				\item{\bf Seria:} Menos de un mes, menos del 5\%, menos del 5\%.
				\item{\bf Menor:} Menos de 15 días, menos del 2\%, menos del 2\%.
				\item{\bf Ignorable:} Impacto no notorio.
			\end{itemize}
		\item{\bf Nivel de Riesgo:} Una vez definidas la probabilidad y severidad de cada riesgo calcularemos el nivel de riesgo de acuerdo al baremos ofrecido por \gls{SQUASSEI} y que se detalla a continuación:
		\begin{itemize}
			\item{\bf Intolerable:} No puede obviarse su gestión bajo ningún concepto.
			\item{\bf Alto:} Si sucede tiene una grave trascendencia. Debería controlarse, supervisarse y tener planes de contingencia.
			\item{\bf Medio:} Si sucede, afecta a los objetivos, costes o planificación. Debería controlarse.
			\item{\bf Bajo:} Si sucede, los efectos son asumibles.
			\item{\bf Tolerable:} Si sucede no importa.
		\end{itemize}
	\end{itemize}
	Nos hemos decantado por esta alternativa ya que , aunque un riesgo tenga una severidad baja, si se presenta muy frecuentemente obstaculizará mucho el proceso de desarrollo
	
	Los riesgos que pueden aparecer durante el desarrollo del proyecto se muestran a continuación agrupados en riesgos de proyecto, técnicos y de negocio:
				

\section{Riesgos del proyecto}
	
\subsection{Riesgos del proyecto}
\subsubsection{Modificación de requisitos}

	\begin{enumerate}
		\item R~\ref{riesgo:cambiosEspecificacionCliente} \label{riesgo:cambiosEspecificacionCliente} Cambios en la especificación del cliente.
			\begin{itemize}
				\item {\bf Descripción:} El cliente puede solicitar que se incorporen nuevos requisitos o que se modifiquen 
				requisitos ya conocidos en cualquier momento del desarrollo del sistema. La modificación de los requisitos puede deberse a dos causas principales: 
				En las primeras fases del desarrollo el cliente está aún descubriendo sus propias necesidades respecto a la aplicación. Además, el propio 
				proceso de identificación y análisis de requisitos realizado por el equipo de desarrollo puede hacer aflorar nuevas ideas y necesidades a los ojos del cliente.
				\item {\bf Probabilidad:} Probable.

				La aparición de este riesgo será frecuente en la \gls{faseInicio}, probable en la \gls{faseElaboracion}, y ocasional en la \gls{faseConstruccion} y \gls{faseTransicion}.
				\item {\bf Severidad:} Seria.
				\item {\bf Nivel de riesgo:} Alto.
			\end{itemize}
	\end{enumerate}
\subsubsection{Cliente}
	\begin{enumerate}
	\setcounter{enumi}{1}
		\item R~\ref{riesgo:planNoEquilibrado} \label{riesgo:planNoEquilibrado}El plan, los recursos y la definición de producto han sido dictados por el cliente y no están equilibrados.
			\begin{itemize}
				\item {\bf Descripción:} La tipología de cliente autoritario impone el plan, los recursos y los requisitos sin ser consensuados de manera 
				que no se ajusta la capacidad de la empresa con las expectativas del cliente.
				\item {\bf Probabilidad:} Improbable.
				\item {\bf Severidad:} Crítica.
				\item {\bf Nivel de riesgo:} Bajo.
			\end{itemize}
		\item \label{riesgo:cambioFechaEntrega1} R~\ref{riesgo:cambioFechaEntrega1} Cambios de fecha de entrega, sin cambios en el contenido a entregar.
			\begin{itemize}
				\item {\bf Descripción:} La fecha de entrega es modificada y el cliente es inflexible en cuanto al contenido de la misma; lo que supone un descenso de la productividad del equipo al tener que asignar a una determinada tarea más recursos de los estimados inicialmente.
				\item {\bf Probabilidad:} Ocasional.
				\item {\bf Severidad:} Menor. 
				
				La severidad de la presentación de este riesgo está condicionada por el tiempo que se adelante.
				\item {\bf Nivel de riesgo:} Bajo.
			\end{itemize}
		\item \label{riesgo:retrasoCorrecciones}R~\ref{riesgo:retrasoCorrecciones} Retrasos en las correcciones de entregas impiden el avance del desarrollo.
			\begin{itemize}
				\item {\bf Descripción:} Las revisiones del cliente se retrasan y la ausencia de aceptación o rechazo de las mismas (correcciones del profesor) impide el avance del proyecto.
				\item {\bf Probabilidad:} Probable. 
				
				La inminente paternidad del profesor hace factible la aparición de este riesgo.
				\item {\bf Severidad:} Menor.
				\item {\bf Nivel de riesgo:} Medio.
			\end{itemize}
		\item \label{riesgo:clienteInsatisfecho}R~\ref{riesgo:clienteInsatisfecho} El cliente encuentra en última instancia el producto insatisfactorio, requiriendo reajustes
			\begin{itemize}
				\item {\bf Descripción:} Errores de comunicación con el cliente hacen que se desarrolle un producto que no se ajusta con las perspectivas que tenía el cliente. 
				Este desajuste entre el producto desarrollado y las necesidades del cliente se detecta en la \gls{faseTransicion}.
				\item {\bf Probabilidad:} Remota.
				\item {\bf Severidad:} Catástrofica.
				\item {\bf Nivel de riesgo:} Alto.
			\end{itemize}
	\end{enumerate}
	
	\subsubsection{Recursos}
	\begin{enumerate}
	\setcounter{enumi}{5}
		\item \label{riesgo:perdidaDatos}R~\ref{riesgo:perdidaDatos} Pérdida de datos.
			\begin{itemize}
				\item {\bf Descripción:} Durante el desarrollo puede perderse información sensible (documentación, códigos fuente...) debido a sobreescritura de archivos, 
				eliminación accidental, sustracción, pérdida o avería de equipos de trabajo...
				\item {\bf Probabilidad:} Probable.
				\item {\bf Severidad:} Seria.
				\item {\bf Nivel de riesgo:} Alto.
			\end{itemize}
	\end{enumerate}
	
	\subsubsection{Planificación temporal}
	\begin{enumerate}
	\setcounter{enumi}{6}
		\item \label{riesgo:planOptimista}R~\ref{riesgo:planOptimista} El plan es demasiado optimista, en lugar de realista.
			\begin{itemize}
				\item {\bf Descripción:} En la realización del plan de proyecto se ha optado por un enfoque optimista en lugar de uno conservador. No se han contemplado \glspl{colchon} dentro del \gls{caminoCritico} para hacer frente a imponderables que pudieran surgir durante la vida del proyecto.
				\item {\bf Probabilidad:} Remota.
				\item {\bf Severidad:} Crítica.
				\item {\bf Nivel de riesgo:} Medio.
			\end{itemize}
		\item \label{riesgo:planOmiteTareas}R~\ref{riesgo:planOmiteTareas} El plan omite tareas necesarias.
			\begin{itemize}
				\item {\bf Descripción:} Un mal análisis de los casos de uso, una deficiencia de los mismos o una mala identificación de los requisitos hace que el plan omita tareas necesarias. 
				\item {\bf Probabilidad:} Probable.
				
				La probabilidad en este riesgo depende de la experiencia del equipo de desarrollo en proyectos similares.
				\item {\bf Severidad:} Menor.
				
				La severidad de este riesgo depende de si la tarea omitida forma parte del \gls{caminoCritico} o no.
				\item {\bf Nivel de riesgo:} Medio.
			\end{itemize}
		\item \label{riesgo:esfuerzoMayor}R~\ref{riesgo:esfuerzoMayor} El esfuerzo real es mayor que el estimado.
			\begin{itemize}
				\item {\bf Descripción:} Un error en la estimación del esfuerzo hace que éste sea superior al calculado en un principio.
				\item {\bf Probabilidad:} Ocasional.
				
				La inexperiencia del equipo en este tipo de proyectos hace más probable la materialización  de este riesgo. 
				\item {\bf Severidad:} Seria.
				\item {\bf Nivel de riesgo:} Medio.
			\end{itemize}
		\item \label{riesgo:planAbandonado}R~\ref{riesgo:planAbandonado} El plan de proyecto se abandona por la presión, resultando en desarrollo caótico e ineficaz.
			\begin{itemize}
				\item {\bf Descripción:} Bajo la presión que supone un incumplimiento del plazo de entrega o una imposición del cliente se incumple el plan, dando como resultado un desarrollo caótico del proyecto.
				\item {\bf Probabilidad:} Remota.
				\item {\bf Severidad:} Crítica.
				\item {\bf Nivel de riesgo:} Medio.
			\end{itemize}
		\item \label{riesgo:retrasoEnCascada}R~\ref{riesgo:retrasoEnCascada} Un retraso en una tarea demora en cascada actividades dependientes.
			\begin{itemize}
				\item {\bf Descripción:} Debido a la frecuente y, por otra parte lógica, dependencia de las tareas de un proyecto, el retraso de una de ellas hace que se demoren todas las que tengan una fecha de comienzo condicionada por aquella.
				\item {\bf Probabilidad:} Probable.
				\item {\bf Severidad:} Seria.
				
				La severidad de este riesgo depende de si la tarea demorada se encuentra en el \gls{caminoCritico} o no.
				\item {\bf Nivel de riesgo:} Alto.
			\end{itemize}
		\item \label{riesgo:rVoluntarismos}R~\ref{riesgo:rVoluntarismos} La dirección pone más énfasis en voluntarismos que en el estado exacto que divulga, lo que socava su capacidad de detectar y corregir problemas.
			\begin{itemize}
				\item {\bf Descripción:} La dirección de nuestra empresa, en su afán de quedar bien ante el cliente acaba percibiendo como una realidad sus deseos de cumplimiento de plazos, lo que provoca que sea incapaz de detectar errores o retrasos. Por este hecho las medidas correctoras no llegan a tiempo o simplemente no se producen.
				\item {\bf Probabilidad:} Ocasional.
				\item {\bf Severidad:} Menor.
				\item {\bf Nivel de riesgo:} Bajo.
			\end{itemize}
		\item \label{riesgo:seguimientoPobre}R~\ref{riesgo:seguimientoPobre} Un pobre seguimiento del progreso impide saber que el proyecto está retrasado hasta que se tiene un avance importante.
			\begin{itemize}
				\item {\bf Descripción:} Debido a un déficit en el seguimiento del cumpllimiento del plan hace que nos demos cuenta del retraso del proyecto sin tiempo suficiente para poner en marcha medidas paliativas.
				\item {\bf Probabilidad:} Ocasional.
				\item {\bf Severidad:} Catastrófica.
				\item {\bf Nivel de riesgo:} Intolerable.
			\end{itemize}
	\end{enumerate}
	
	\subsubsection{Personal}
	\begin{enumerate}
	\setcounter{enumi}{13}
		\item \label{riesgo:bajasPersonal}R~\ref{riesgo:bajasPersonal} Bajas del personal del proyecto (por abandono de la asignatura, enfermedad...)
			\begin{itemize}
				\item {\bf Descripción:} Algún integrante del proyecto causa baja en el mismo. La ausencia del integrante del equipo puede ser temporal debida a una enfermedad o definitiva, por abandono de la asignatura.
				\item {\bf Probabilidad:} Frecuente.
				
				Aún así, los casos extremos (abandono de asignatura) son mucho menos probables que una baja temporal.
				\item {\bf Severidad:} Menor.
				
				Se ha tenido en cuenta la alta probabilidad de bajas temporales y la baja probabilidad de bajas definitivas para esta estimación.
				\item {\bf Nivel de riesgo:} Medio.
			\end{itemize}
		\item \label{riesgo:diferenciaAspiraciones}R~\ref{riesgo:diferenciaAspiraciones} Diferencia de aspiraciones de los miembros respecto del proyecto 
			\begin{itemize}
				\item {\bf Descripción:} La heterogeneidad de los integrantes del equipo hace que su predisposición hacia la asignatura sea diferente, así como sus expectativas de nota, lo que redunda en un desequilibrio en el reparto del esfuerzo.
				\item {\bf Probabilidad:} Frecuente.
				\item {\bf Severidad:} Seria.
				\item {\bf Nivel de riesgo:} Alto.
			\end{itemize}
		\item \label{riesgo:productividadMermada}R~\ref{riesgo:productividadMermada} Productividad mermada por presión debida a la concurrencia en el tiempo de otras entregas.
			\begin{itemize}
				\item {\bf Descripción:} Los miembros del equipo participan en el desarrollo de otras aplicaciones (Tecnología de la Programación, Estructura de Datos y Algoritmos), lo que hace factible la coincidencia temporal de dos entregas a diferentes clientes. Esto implicaría una bajada de productividad del equipo debida a la obligación de repartir su esfuerzo entre dos proyectos distintos.
				\item {\bf Probabilidad:} Probable.
				\item {\bf Severidad:} Menor.
				\item {\bf Nivel de riesgo:} Medio.
			\end{itemize}
		\item \label{riesgo:notasIS}R~\ref{riesgo:notasIS} Las notas de IS minan la moral del personal (provocan desinterés...).
			\begin{itemize}
				\item {\bf Descripción:} La existencia de exámenes parciales de la asignatura hace que una eventual mala nota de algún integrante del equipo desarrollador influya negativamente en su moral lo que redundaría en su falta de implicación en el proyecto.
				\item {\bf Probabilidad:} Ocasional.
				\item {\bf Severidad:} Menor.
				\item {\bf Nivel de riesgo:} Bajo.
			\end{itemize}
		\item \label{riesgo:noFeeling}R~\ref{riesgo:noFeeling} Los miembros del equipo no trabajan juntos eficientemente.
			\begin{itemize}
				\item {\bf Descripción:} Debido a que es la primera vez que el equipo trabaja junto, existe la posibilidad de aparición de problemas y discrepancias entre los miembros del equipo, así como falta de acuerdo en la toma de decisiones.
				\item {\bf Probabilidad:} Ocasional.
				\item {\bf Severidad:} Menor.
				\item {\bf Nivel de riesgo:} Bajo.
			\end{itemize}
	\end{enumerate}
	
\subsection{Riesgos técnicos}

	\subsubsection{Generales}
	\begin{enumerate}
	\setcounter{enumi}{18}
		\item \label{riesgo:inexactitudSRS}R~\ref{riesgo:inexactitudSRS} Inexactitud de especificaciones de requisitos.
			\begin{itemize}
				\item {\bf Descripción:} Una incorrecta o ambigua \gls{SRS} dificulta el trabajo de implementación al equipo de desarrollo.
				\item {\bf Probabilidad:} Probable.
				\item {\bf Severidad:} Seria.
				\item {\bf Nivel de riesgo:} Alto.
			\end{itemize}
		\item \label{riesgo:malDisenyo}R~\ref{riesgo:malDisenyo} Un mal diseño del software, lo que conlleva ajustes y modificaciones.
			\begin{itemize}
				\item {\bf Descripción:} Un mal diseño del código dificulta de tal manera el desarrollo de componentes posteriores de manera que necesita ser modificado y reajustado para enfocar el problema desde otro punto de vista.
				\item {\bf Probabilidad:} Remota.
				\item {\bf Severidad:} Seria.
				\item {\bf Nivel de riesgo:} Bajo.
			\end{itemize}
		\item \label{riesgo:noHayHerramientas}R~\ref{riesgo:noHayHerramientas} Las herramientas de desarrollo no están en el lugar y tiempo necesarios (laboratorios, programas...)
			\begin{itemize}
				\item {\bf Descripción:} La existencia de licencias de software en las herramientas \gls{CASE} que utilizaremos en la confección del Plan de desarrollo hace que el acceso a los laboratorios sea clave en determinados momentos.
				\item {\bf Probabilidad:} Probable.
				\item {\bf Severidad:} Menor.
				\item {\bf Nivel de riesgo:} Medio.
			\end{itemize}
		\item \label{riesgo:funcionesAdicionales}R~\ref{riesgo:funcionesAdicionales} El desarrollo de funcionalidades adicionales que no se requieren (virguerías) amplía el plan.
			\begin{itemize}
				\item {\bf Descripción:} Un afán de mejorar la aplicación para hacerla más apetecible al cliente conlleva un aumento de las necesidades de la misma, ampliando el esfuerzo requerido e introduciendo nuevas dificultades técnicas.
				\item {\bf Probabilidad:} Remota.
				\item {\bf Severidad:} Menor.
				\item {\bf Nivel de riesgo:} Tolerable.
			\end{itemize}
	\end{enumerate}
	
	\subsubsection{Implementación}
	\begin{enumerate}
	\setcounter{enumi}{22}
		\item \label{riesgo:migracionDatos}R~\ref{riesgo:migracionDatos} Problemas en la migración de datos (de su sistema actual al nuevo), restricciones por la implementación para sistemas específicos (técnicas anticuadas).
			\begin{itemize}
				\item {\bf Descripción:} El hecho de que la empresa esté trabajando en la actualidad con una aplicación de gestión hace que tengan una base de datos de clientes y ventas que es necesario migrar al nuevo sistema. Esto provoca dificultades técnicas y en ocasiones encorseta la implementación. Asimismo la necesidad de adaptarse a los equipos existentes en las diferentes tiendas obliga a tenerlo en cuenta en el desarrollo de nuestro software.
				\item {\bf Probabilidad:} Ocasional.
				\item {\bf Severidad:} Crítica.
				
				Es un riesgo que influye directamente en la \gls{faseTransicion} y retrasa inexorablemente la puesta en marcha de la aplicación.
				\item {\bf Nivel de riesgo:} Alto.
			\end{itemize}
	\end{enumerate}
	
	\subsubsection{Interfaces}
	\begin{enumerate}
	\setcounter{enumi}{23}
		\item \label{riesgo:problemasHardware}R~\ref{riesgo:problemasHardware} Problemas con la capturadora de etiquetas, conexión con la impresora...
			\begin{itemize}
				\item {\bf Descripción:} Dificultades técnicas en la comunicación (\glspl{protocolo}) de los elementos hardware necesarios para el funcionamiento de la aplicación aumentan el esfuerzo necesario del desarrollo.
				\item {\bf Probabilidad:} Ocasional.
				\item {\bf Severidad:} Menor.
				\item {\bf Nivel de riesgo:} Bajo.
			\end{itemize}
	\end{enumerate}

	\subsubsection{Verificación}
	\begin{enumerate}
	\setcounter{enumi}{24}
		\item \label{riesgo:problemasClaves}R~\ref{riesgo:problemasClaves} Desconocimiento de la gestión de claves y la \gls{encriptacion} de las mismas.
			\begin{itemize}
				\item {\bf Descripción:} El equipo de desarrollo no está ejercitado en el manejo de claves y herramientas de \gls{encriptacion}, necesarias para el cumplimiento de la \gls{lopd}.
				\item {\bf Probabilidad:} Remota.
				\item {\bf Severidad:} Menor.
				
				La aparición de este riesgo sería muy peligrosa para el proyecto, pues pone en riesgo elementos relacionados con la seguridad de la aplicación. Sin embargo, al ser de solución muy fácil, no lo consideramos muy severo.
				\item {\bf Nivel de riesgo:} Tolerable.
			\end{itemize}
	\end{enumerate}
	
	\subsubsection{Mantenimiento}
	\begin{enumerate}
	\setcounter{enumi}{25}
		\item \label{riesgo:cambiosBDoInterfaces}R~\ref{riesgo:cambiosBDoInterfaces} Cambios en la estructura de la base de datos o cambios en las interfaces.
			\begin{itemize}
				\item {\bf Descripción:} Modificaciones en los elementos con los que interactúa la aplicación pueden acarrear cambios en ésta, debido a la imposibilidad de compaginar las diferentes versiones. Por eso se necesitan desechar partes ya diseñadas de la aplicación para volver a construirlas, incrementando esfuerzo y costes.
				\item {\bf Probabilidad:} Remota.
				\item {\bf Severidad:} Menor.
				\item {\bf Nivel de riesgo:} Tolerable.
			\end{itemize}
	\end{enumerate}

\subsection{Riesgos de negocio}
	\subsubsection{Generales}
	\begin{enumerate}
	\setcounter{enumi}{26}
		\item \label{riesgo:noDaTiempo}R~\ref{riesgo:noDaTiempo} No poder construir un producto del tamaño especificado en el tiempo asignado.
			\begin{itemize}
				\item {\bf Descripción:} Un error en el cálculo del esfuerzo hace que no sea posible cumplir las fechas de entrega comprometidas con el cliente. La imposibilidad del cumplimiento de las fechas de entrega pone en riesgo la continuidad del contrato firmado con el cliente.
				\item {\bf Probabilidad:} Remota.
				\item {\bf Severidad:} Catastrófica.
				\item {\bf Nivel de riesgo:} Alto.
			\end{itemize}
	\end{enumerate}


\pagebreak %para que la tablilla empiece en una nueva hojilla. vecinillo

\section{Tabla de priorización}
	Presentamos a continuación una tabla resumen con los riesgos ordenados de mayor a menor nivel de riesgo, siendo los de nivel de riesgo Intolerable y Alto los que va a ser objeto de estudio detallado en la siguiente sección.
	\\ \\ 

\bottomcaption{Relación de riesgos}     % Subtitulo de la tabla.
\tablehead {\multicolumn{1}{c}{\bfseries ID.} & \bfseries Descripción & \bfseries Probab. & \bfseries Consecuencia & \multicolumn{1}{c}{\bfseries Nivel} \\ \hline} % Títulos de las columnas.
\tabletail {\hline \multicolumn{3}{r}{\emph{Continúa en la página siguiente}}\\} % Cola de tabla cuando salta a la siguiente página
\tablelasttail{\\ \hline}
\begin{supertabular*}{15.5cm}{|m{1.5cm}m{5.85cm}ccc|}
R~\ref{riesgo:seguimientoPobre} & Un pobre seguimiento del progreso impide saber que el proyecto está retrasado hasta que se tiene un avance importante. & Ocasional & Castrófica & Intolerable \\ \hline
R~\ref{riesgo:cambiosEspecificacionCliente} & Cambios en la especificación del cliente & Probable & Seria & Alto \\ \hline
R~\ref{riesgo:clienteInsatisfecho} & El cliente encuentra en última instancia el producto insatisfactorio, requiriendo reajustes. & Remota & Catastrófica & Alto \\ \hline
R~\ref{riesgo:perdidaDatos} & Pérdida de datos. & Probable & Seria & Alto\\ \hline
R~\ref{riesgo:retrasoEnCascada} & Un retraso en una tarea demora en cascada actividades dependientes. & Probable & Seria & Alto\\ \hline
R~\ref{riesgo:diferenciaAspiraciones} & Diferencia de aspiraciones de los miembros respecto del proyecto  & Frecuente & Seria & Alto\\ \hline
R~\ref{riesgo:inexactitudSRS} & Inexactitud de especificaciones de requisitos. & Probable & Seria & Alto\\ \hline
R~\ref{riesgo:migracionDatos} & Problemas en la migración de datos (de su sistema actual al nuevo), restricciones por la implementación para sistemas específicos (técnicas anticuadas). & Ocasional & Crítica & Alto\\ \hline
R~\ref{riesgo:noDaTiempo} & No poder construir un producto del tamaño especificado en el tiempo asignado. & Remota & Catastrófica & Alto \\ \hline
R~\ref{riesgo:retrasoCorrecciones} & Retrasos en las correcciones de entregas impiden el avance del desarrollo. & Probable & Menor & Medio\\ \hline
R~\ref{riesgo:planOptimista} & El plan es demasiado optimista, en lugar de realista. & Remota & Crítica & Medio\\ \hline
R~\ref{riesgo:planOmiteTareas} & El plan omite tareas necesarias. & Probable & Menor & Medio\\ \hline
R~\ref{riesgo:esfuerzoMayor}  & El esfuerzo real es mayor que el estimado. & Ocasional & Seria & Medio\\ \hline
R~\ref{riesgo:planAbandonado} & El plan de proyecto se abandona por la presión, resultando en desarrollo caótico e ineficaz. & Remota & Crítica & Medio\\ \hline
R~\ref{riesgo:bajasPersonal} & Bajas del personal del proyecto (por abandono de la asignatura, enfermedad...) & Frecuente & Menor & Medio\\ \hline
R~\ref{riesgo:productividadMermada} & Productividad mermada por presión debida a la concurrencia en el tiempo de otras entregas. & Probable & Menor & Medio\\ \hline
R~\ref{riesgo:noHayHerramientas} & Las herramientas de desarrollo no están en el lugar y tiempo necesarios (laboratorios, programas...) & Probable & Menor & Medio\\ \hline
R~\ref{riesgo:notasIS} & Las notas de IS minan la moral del personal (provocan desinterés...). & Ocasional & Menor & Bajo\\ \hline
R~\ref{riesgo:noFeeling} & Los miembros del equipo no trabajan juntos eficientemente. & Ocasional & Menor & Bajo\\ \hline
R~\ref{riesgo:planNoEquilibrado} & El plan, los recursos, y la definición de producto han sido dictados por el cliente y no están equilibrados. & Improbable & Crítica & Bajo\\ \hline
R~\ref{riesgo:cambioFechaEntrega1} & Cambios de fecha de entrega sin cambios en el contenido a entregar & Ocasional & Menor & Bajo\\ \hline
R~\ref{riesgo:rVoluntarismos} & La dirección pone más énfasis en voluntarismos que en el estado exacto que divulga, lo que socava su capacidad de detectar y corregir problemas. & Ocasional & Menor & Bajo\\ \hline
R~\ref{riesgo:malDisenyo} & Mal diseño del software lo que conlleva ajustes y modificaciones. & Remota & Seria & Bajo\\ \hline
R~\ref{riesgo:problemasHardware} & Problemas con la capturadora de etiquetas, conexión con la impresora... & Ocasional & Menor & Bajo\\ \hline
R~\ref{riesgo:funcionesAdicionales} & El desarrollo de funcionalidades adicionales que no se requieren (virguerías) amplía el plan. & Remota & Menor & Tolerable\\ \hline
R~\ref{riesgo:problemasClaves} & Desconocimiento de la gestión de claves y la \gls{encriptacion} de las mismas. & Remota & Menor & Tolerable\\ \hline
R~\ref{riesgo:cambiosBDoInterfaces} & Cambios en la estructura de la base de datos o cambios en las interfaces. & Remota & Menor & Tolerable
\end{supertabular*}


\pagebreak

\chapter{Reducción, supervisión y gestión del riesgo}
	En esta sección se estudian detalladamente los riesgos que más impacto se espera que tengan en nuestro proyecto. Son los que han sido catalogados con nivel de riesgo intolerable o alto. \\
	Bajo el epígrafe de supervisión, se determina para cada riesgo la forma de identificarlo. Asimismo se detallará el plan de gestión, dividido en las tareas de prevención, reducción del riesgo y plan de contingencia.
\paragraph{R~\ref{riesgo:seguimientoPobre} Un pobre seguimiento del progreso impide saber que el proyecto está retrasado hasta que se tiene un avance importante.}
	\begin{itemize}
		\item{\bf Probabilidad:} Ocasional.
		\item{\bf Severidad:} Catastrófica.
		\item{\bf Nivel de riesgo:} Intolerable.
		\item{\bf Supervisión:} El responsable del seguimiento del Plan de Proyecto hace tiempo que no notifica en las reuniones sobre el cumplimiento o no del mismo. Al contrastar el avance actual con el esperado se descubren retrasos importantes.
		\item{\bf Gestión:} 
			\begin{itemize}
				\item{\bf Prevención:} El responsable del Plan tendrá obligación de presentar un informe periódico acerca del cumplimiento del Plan. Cada miembro del equipo desarrollador informará en las reuniones periódicas sobre el cumplimiento de \gls{deadlines} de las tareas que le han sido asignadas.
				\item{\bf Reducción:} No existe plan de reducción de este riesgo debido a las características del mismo. Por lo tanto tras su aparición se acudiría inmediatamente al Plan de contingencia.
				\item{\bf Plan de contingencia:} Se estimará el tiempo total de retraso acumulado, se rediseñará el Plan de desarrollo para adaptarlo a la nueva situación para lo cual habrá que reasignar tareas.
				
				Si el cumplimiento de la fecha de entrega se ve afectado, se notificará al cliente y se intentará negociar un retraso de la entrega.
				
				Se cambiará el responsable del seguimiento del Plan de Proyecto. 
			\end{itemize}
	\end{itemize}
\paragraph{R~\ref{riesgo:cambiosEspecificacionCliente} Cambios en la especificación del cliente}
	\begin{itemize}
		\item{\bf Probabilidad:} Probable.
		\item{\bf Severidad:} Seria.
		\item{\bf Nivel de riesgo:} Alto.
		\item{\bf Supervisión:} El cliente anuncia al equipo de desarrollo el cambio de requisitos, o aparecen nuevos requisitos en reuniones con el cliente.
		\item{\bf Gestión:} 
			\begin{itemize}
				\item{\bf Prevención:} Hacer una sistemática identificación de requisitos en la \gls{faseInicio} para limitar el impacto de la aparición de nuevos requisitos a mitad de proyecto. Para ello las reuniones con el cliente en la \gls{faseInicio} serán muy numerosas y se hará un acta con los requisitos que se hayan ido identificando.
				\item{\bf Reducción:} Debido a que la aparición de nuevos requisitos es potestativa del cliente no podremos reducir el riesgo aunque sí podremos prevenir que haya requisitos existentes pero no identificados.
				\item{\bf Plan de contingencia:} En la \gls{faseInicio} se incorporarán los nuevos requisitos sin que ocasionen graves perjuicios en el plan de desarrollo. En la \gls{faseConstruccion} y la \gls{faseTransicion} se ponderará la repercusión que estos cambios tendrán en el proyecto en relación con el tiempo restante.
				
				En caso de que se decida aceptarlos, se negociará con el cliente una lista de nuevos requisitos, así como una eventual ampliación del plazo de entrega, levantando acta de todo ello.
				
				Los nuevos requisitos se estudiarán minuciosamente y en una reunión de todo el grupo se establecerán los cambios para satisfacer los nuevos requisitos que afectarán a los revisarán los documentos de Casos de Uso, la \gls{SRS}, el presente plan \gls{RSGR}, el plan de desarrollo, etc. , así como el código derivado de los mismos.
			\end{itemize}
	\end{itemize}
\paragraph{R~\ref{riesgo:clienteInsatisfecho} El cliente encuentra en última instancia el producto insatisfactorio, requiriendo reajustes.}
	\begin{itemize}
		\item{\bf Probabilidad:} Remota.
		\item{\bf Severidad:} Catastrófica.
		\item{\bf Nivel de riesgo:} Alto.
		\item{\bf Supervisión:} En una reunión con el cliente de la \gls{faseTransicion}, éste muestra su insatisfacción con el producto entregado.
		\item{\bf Gestión:} 
			\begin{itemize}
				\item{\bf Prevención:} Actualizaciones periódicas de un prototipo que muestre el avance realizado y de una idea al cliente de lo que será el producto final.
				\item{\bf Reducción:} Levantar acta de reuniones previas en las que el cliente valide el prototipo entregado en las mismas.
				\item{\bf Plan de contingencia:} Debido a que este riesgo se presentaría en la \gls{faseTransicion}, se renegociará una nueva fecha de entrega con el cliente y se retomará el proyecto desde la última entrega validada.
			\end{itemize}
	\end{itemize}
\paragraph{R~\ref{riesgo:perdidaDatos} Pérdida de datos}
	\begin{itemize}
		\item{\bf Probabilidad:} Probable.
		\item{\bf Severidad:} Seria.
		\item{\bf Nivel de riesgo:} Alto.
		\item{\bf Supervisión:} Los desarrolladores detectan una pérdida o avería de los equipos de trabajo, cambios no reflejados en los documentos o corrupción de los mismos.
		\item{\bf Gestión:} 
			\begin{itemize}
				\item{\bf Prevención:} Utilización de repositorios \gls{svn} ajenos a Cauchy Team. Hemos optado en este caso por \gls{googleCode}.
				\item{\bf Reducción:} Realización de \glspl{commit} con frecuencia para evitar el riesgo de avería del equipo o errores humanos en la actualización de archivos.
				\item{\bf Plan de contingencia:} Recuperación de una versión anterior para lo que nos será de utilidad del plan de gestión de la configuración.
			\end{itemize}
	\end{itemize}
\paragraph{R~\ref{riesgo:retrasoEnCascada} Un retraso en una tarea demora en cascada actividades dependientes.}
	\begin{itemize}
		\item{\bf Probabilidad:} Probable.
		\item{\bf Severidad:} Seria.
		\item{\bf Nivel de riesgo:} Alto.
		\item{\bf Supervisión:} En el seguimiento del Plan de Desarrollo se advierte un retraso en una tarea, notándose la alta dependencia de otras sobre la primera. Éste hecho demorará consecuentemente las tareas dependientes, en un grado incremental hacia las últimas de la cadena.
		\item{\bf Gestión:} 
			\begin{itemize}
				\item{\bf Prevención:} Diseño del plan de proyecto de manera que no haya grandes dependencias entre tareas, aliviando el \gls{caminoCritico} para que se abran varias ramas de trabajo por si una queda atascada. Se pondrá empeño en que el plan de proyecto sea realista y no optimista, dejando \glspl{colchon} en las tareas que puedan absorber eventuales retrasos no contemplados.
				\item{\bf Reducción:} Involucrar a los miembros del equipo en las diferentes tareas, de manera que conozcan la manera de trabajar en todas ellas.
				\item{\bf Plan de contingencia:} Al retrasarse una tarea, los miembros del equipo que tengan asignadas las tareas dependientes se moverán a trabajar a otras de otra rama. De esta manera se seguirá avanzando en el proyecto por otros caminos hasta que quede liberada la tarea con retraso.
			\end{itemize}
	\end{itemize}
\paragraph{R~\ref{riesgo:diferenciaAspiraciones} Diferencia de aspiraciones de los miembros respecto del proyecto.}
	\begin{itemize}
		\item{\bf Probabilidad:} Frecuente.
		\item{\bf Severidad:} Seria.
		\item{\bf Nivel de riesgo:} Alto.
		\item{\bf Supervisión:} Un integrante del equipo muestra desidia y falta de interés en la realización del proyecto. No se preocupa de las fechas de las entregas ni aporta iniciativas al grupo.
		\item{\bf Gestión:} 
			\begin{itemize}
				\item{\bf Prevención:} Reuniones informales fuera del ámbito de trabajo que permitan compenetrar a los miembros del grupo y que cada uno de los integrantes del equipo perciba como propias las aspiraciones del resto.
				\item{\bf Reducción:} En el caso de que algún miembro del personal muestre desánimo o falta de implicación, el resto del equipo le ofrecerá su apoyo y ayuda.
				\item{\bf Plan de contingencia:} Reparto proporcional del esfuerzo entre el resto de los miembros del equipo, y notificación de este hecho al profesor.
			\end{itemize}
	\end{itemize}
\paragraph{R~\ref{riesgo:inexactitudSRS} Inexactitud de especificaciones de requisitos. }
	\begin{itemize}
		\item{\bf Probabilidad:} Probable.
		\item{\bf Severidad:} Seria.
		\item{\bf Nivel de riesgo:} Alto.
		\item{\bf Supervisión:} El equipo de desarrollo detecta errores en la \gls{SRS} que impiden o dificultan el avance del proyecto. Estos errores requieren de una profunda modificación de la \gls{SRS} para subsanarse, lo que retrasa el proyecto y potencialmente obliga a realizar cambios sobre tareas ya terminadas.
		\item{\bf Gestión:} 
			\begin{itemize}
				\item{\bf Prevención:} Revisiones a fondo de los requisitos resultantes de las reuniones con el cliente, especificándolos detalladamente para poder verificar que sean correctos y no contengan ambigüedades o inconsistencias entre ellos.
				\item{\bf Reducción:} Reuniones con el cliente donde éste supervise la \gls{SRS} realizada por el equipo, para que detecte cualquier error antes de que sea demasiado tarde.
				\item{\bf Plan de contingencia:} Dado que el cliente supervisaba la \gls{SRS} y los requisitos estaban claramente definidos en las actas correspondientes, si desea realizar cambios se propondrán rutas alternativas donde no sea necesaria una reestructuración de la \gls{SRS}, acordando modificaciones mínimas sobre el producto final. En casos extremos donde sea necesaria la reestructuración se negociarán nuevas fechas de entrega.
			\end{itemize}
	\end{itemize}
\paragraph{R~\ref{riesgo:migracionDatos} Problemas en la migración de datos (de su sistema actual al nuevo), restricciones por la implementación para sistemas específicos (técnicas anticuadas).}
	\begin{itemize}
		\item{\bf Probabilidad:} Ocasional.
		\item{\bf Severidad:} Crítica.
		\item{\bf Nivel de riesgo:} Alto.
		\item{\bf Supervisión:} Al realizar la transición de la aplicación antigua a la nuestra, se detectan problemas y dificultades al copiar la base de datos existente al nuevo sistema. Al interactuar el nuevo software con las interfaces y hardware preexistentes.
		\item{\bf Gestión:} 
			\begin{itemize}
				\item{\bf Prevención:} \Glspl{simulacion} previas con \glspl{emuladorHardware} o, idealmente, con el propio hardware solicitando al cliente esta posibilidad. Pruebas con clones de la base de datos que hay que migrar para comprobar que el \glspl{protocolo} diseñado para su copia funcione.
				\item{\bf Reducción:} Se recurrirá a los resultados de las pruebas realizadas para aislar el problema y aplicar los mismos procesos seguidos en las \glspl{simulacion}, asegurando una mayor fiabilidad de la transición.
				\item{\bf Plan de contingencia:} Realización de nuevo de las pruebas, haciendo hincapié en los problemas derivados de la transición, aislando de esta manera el espectro de errores. Se hablará con el cliente para extender el periodo de transición si se fueran a producir retrasos, dejando mientras tanto el sistema previo en funcionamiento.
			\end{itemize}
	\end{itemize}
\paragraph{R~\ref{riesgo:noDaTiempo} No poder construir un producto del tamaño especificado en el tiempo asignado.}
	\begin{itemize}
		\item{\bf Probabilidad:} Remota.
		\item{\bf Severidad:} Catastrófica.
		\item{\bf Nivel de riesgo:} Alto.
		\item{\bf Supervisión:} Se acerca la fecha acordada para la entrega de una determinada parte del proyecto y hay retrasos con respecto a la planificación.
		\item{\bf Gestión:} 
			\begin{itemize}
				\item{\bf Prevención:} Seguir estrictamente los plazos marcados en el Plan de Proyecto y notificar a los encargados del seguimiento del mismo los retrasos que se produzcan en cada tarea. Cada encargado de una tarea deberá mantener una relación de tareas finalizadas y pendientes junto con el tiempo disponible para realizarlas.
				\item{\bf Reducción:} Intentar que los responsables de las tareas afectadas se involucren y trabajen más de lo planificado.
				\item{\bf Plan de contingencia:} Se dará prioridad a los módulos del sistema que queden por desarrollar. La funcionalidad de los diferentes módulos se reducirá en la medida de lo posible para conseguir entregar a tiempo.
				
				Se intentará un aplazamiento de la fecha de entrega.
			\end{itemize}
	\end{itemize}

\chapter{Planificación temporal}

\section{Organización}
	En principio todos los miembros del equipo colaborarán en la identificación de nuevos riesgos que pueden aparecer durante el desarrollo de cualquier parte del proyecto.
	
	Los miembros encargados de mantener actualizado este documento y de incorporar nuevos riesgos al mismo así como de modificar el tratamiento dado a alguno de ellos son Daniel Báscones e Iñigo Zunzunegui, con independencia de que un hipotético sistema de turnos encargue esta responsabilidad a otros en un futuro.
\section{Metodología de la planificación temporal}
	Para mantener el presente documento, así como para detectar nuevos riesgos y revisar y actualizar el plan de gestión de cada uno de los riesgos significativos vamos a utilizar la siguiente metodología:
	\begin{itemize}
		\item{\bf Identificación de nuevos riesgos:} En las reuniones periódicas del grupo se hará una puesta en común de nuevos riesgos detectados por cualquiera de los miembros del equipo. Esto dará lugar a una lista de nuevos riesgos.
		\item{\bf Auditoría de la gestión de riesgos:} En las reuniones periódicas se hará una puesta en común de los resultados de la aplicación del plan de gestión de riesgo. Esto dará lugar a una propuesta de modificación y mejora del tratamiento de los riesgos ya existentes.
		\item{\bf Contingencias:} En cualquier momento del proceso un integrante que detecte un nuevo riesgo o un déficit de gestión en alguno ya existente se pondrá en contacto con los responsables de este documento que valorarán la posibilidad de convocar una reunión para tratar esta eventualidad o la resolverán independientemente del resto del grupo.
	\end{itemize}
\section{Responsabilidades}
	Los encargados de mantener este documento de gestión de riesgos deberán:
	\begin{itemize}
		\item Valorar la probabilidad y severidad de cada uno de los nuevos riesgos detectados.
		\item En caso de que determinen que el nuevo riesgo identificado tiene un nivel de riesgo relevante, elaborarán un plan de gestión del mismo, o extenderán el de uno semejante para que incluya al nuevo riesgo detectado
		\item Revisar los planes de gestión de los riesgos ya tratados, incorporando las propuestas que surjan del las auditorías periódicas del plan.
	\end{itemize}
	Todos los integrantes del grupo que trabajen en el proyecto deberán:
	\begin{itemize}
		\item Ser conocedores de la existencia de este documento y estar al tanto de los riesgos que el mismo contempla.
		\item Consultar el plan de gestión de riesgos tan pronto como detecten la aparición de uno y poner en marcha la implementación de las medidas correctoras en él descritas.
		\item Notificar la existencia de nuevos riesgos o las carencias del plan de gestión de riesgos detectadas.
	\end{itemize}
\section{Resumen}
	Se han identificado en este documento 27 riesgos. En la priorización se ha determinado estudiar en profundidad los riesgos catalogados con un nivel de riesgo  intolerable o alto, lo que ha dejado una lista de 9 riesgos de los que se ha realizado un plan de Gestión.